Offer a footer Cancel on a stepper command dialog - #129

Reviewer context — resolves #121. Commits 33ded98 (props + button) and 09a399a (specs).

The cancel path already existed

onHide has always routed through handleClose(DialogResult.Cancelled), whose cancel arm already fans out to onCancel → onClose → the dialog context. Nothing was invented; this only surfaces that path as a button. showCancel defaults to false — turning it on by default would silently re-lay-out every wizard already in use, which would be a major.

Position: leftmost, before Previous and outside the flex-1 spacer, so it does not slide across when Previous appears on step 2.

Why the specs run in a DOM

The repo default is environment: 'node' with renderToStaticMarkup, which never runs effects and cannot dispatch a click. Under it these specs could prove a button with the right label exists and nothing more — and a cancel that quietly closed as confirmed would look identical. All six files opt into jsdom and click the real button.

The load-bearing assertion is which arm ran: onCancel fired, onConfirm did not, context closed with Cancelled. and_submit_is_clicked_instead.ts exists purely as a control, proving the harness can observe the Ok arm — otherwise "confirm never ran" would be unfalsifiable.

Verification

Orchestrator re-ran independently: tsc clean, 156 files / 425 tests (baseline 150/397 — exactly the 6 files and 28 assertions added). StepperCommandDialog.tsx verified byte-identical to HEAD in the spec commit — the specs changed no production code.

12 mutations, each trap-guarded and restored from a byte backup. Headline: flipping the button's DialogResult.Cancelled → Ok kills 6 assertions including should_close_with_cancelled. Every one of the 28 new assertions dies to at least one break; 26 of 28 die to a single-line break.

Three things stated plainly rather than papered over

M10 is a multi-line mutation. No single-line edit moves Cancel relative to Previous — it takes a 9-line block move. The step-dependence axis is covered single-line (M5, M6); pure reordering is not.

A real gap was found and closed mid-way. Button order alone cannot distinguish "before the spacer" from "after it" on the first step, where there is no Previous between them — exactly the cell where the position claim needed proving. The layout helper now describes the spacer, and every mutation whose target specs changed was re-run.

One assertion is only non-vacuous by proximity. should_ignore_a_cancel_click_while_the_command_runs stays green when the button is deleted entirely (no button → zero calls → satisfied). It is saved by two siblings in the same beforeEach that do redden. Worth knowing before anyone splits that file.

Not pinned

• Visual order. The specs assert DOM child order; a CSS flex-row-reverse or order: would move Cancel on screen with the DOM untouched and nothing would notice.
• Busy × middle step is unreachable by construction — isBusy is set only by handleSubmit, wired only to Submit, which renders only on the last step. Covered via a single-step wizard instead.

A candidate vacuity species — the obedient double

Every spec in this folder mocks primereact/button, and the mock forwards disabled to a real <button disabled>. That mock, not PrimeReact, is what gives disabled its meaning. If the shipped Button ignored disabled in favour of some other prop, every busy assertion here would still be green.

Distinct from "asserting through a blind interface" (which never calls the real thing) and from "a downstream stage launders the defect" (where the real downstream refuses the bad value): here the downstream is replaced by a more obedient one, so the spec grades the mock's contract rather than the library's. Any mocked-boundary component spec inherits it. The honest scope of these specs is "the dialog asks for the right thing" — not "the shipped button obeys."

Reviewer context for the two commits just pushed. Two fresh independent reviewers (code and security) looked at this branch; both found merge-blocking problems, and this addresses all of them.

The spec that could not fail

should_ignore_a_cancel_click_while_the_command_runs was unfalsifiable. jsdom's HTMLElement.click() returns early on a disabled control, so no click event is ever dispatched — the assertion only ever observed button.disabled === true, which is exactly what its sibling should_disable_cancel_while_the_command_runs already asserted. Both died to the same character.

The second suite made it worse: it carried that assertion with no "honored once it returns" counterpart, so deleting the onClick handler entirely left it green. It only reddened because the first suite happened to live in the same file.

Fixed by settling the run and clicking again inside the second suite, and renaming the overclaiming assertion to should_take_cancel_out_of_the_click_path_while_the_command_runs. It was renamed rather than deleted because it is the "before" half of a window — without it, the new assertion would be satisfied equally by a click that landed while the command was still running.

Independently re-verified before merge. Baseline: 11/11 green. Deleting onClick={() => handleClose(DialogResult.Cancelled)} from the footer button: 2 failed / 9 passed, including should_honor_a_cancel_click_once_the_command_returns at and_the_command_is_executing.ts:235. The hole is closed. The file was restored byte-identically afterwards and confirmed with diff.

Every new assertion, and the single line it dies to

Both regressions are caught: restoring the old handleSubmit ordering fails should_report_no_cancellation_to_the_dialog_context; restoring hardcoded closable fails four assertions.

One line I could not independently falsify — stating it rather than hiding it

closeOnEscape={!isBusy} at :324 has no mutation that kills it alone. PrimeReact computes isCloseOnEscape = props.closable && props.closeOnEscape && visibleState, so closable={!isBusy} already blocks Escape; flipping closeOnEscape back to always-true produces zero failures. The Escape assertions are still non-vacuous — they die to :228 — but :324 itself is defense in depth, not a uniquely pinned guard.

It was kept deliberately: it states intent and holds the Escape path on its own terms if closable is ever loosened. The mock models PrimeReact's real conjunction rather than a convenient fiction, which is why the gap is visible at all. Happy to drop it if the preference is strict falsifiability over defense in depth — behavior is identical either way.

Gates

yarn lint 0 errors · npx vitest run (full suite, not targeted) 159 files / 436 tests, 0 failed · npx tsc -b 0 errors · markdownlint-cli2 on the changed doc, 0 issues.

Note: tsconfig.json excludes **/for_*/**, so spec files are never type-checked by tsc -b. Pre-existing, not introduced here.

Adjacent, deliberately out of scope

CommandDialog.tsx has the same onBeforeExecute-before-busy shape and no closable/closeOnEscape guard, so both defects likely exist there too. Fixing it would widen this PR well past the stepper; worth its own change.

Not verified

No browser was driven — the evidence is jsdom plus the mutation runs above. The async-transform window was reproduced in a spec, not observed against a real slow command.